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FILE TRANSFER PROTOCOL 
Meeting Announcement and a New Proposed Document 


Attached is a new proposal for a File Transfer Protocol. The 
document is an extensive update to RFC 354 and, I believe, 
incorporates solutions to most of the objections to RFC 354. 


It now seems appropriate to make another attempt to reach final 
agreement on FTP. Accordingly, I am calling a meeting of interested 
parties, to be held at BBN on March 16, for discussion of this and 
other proposals. 


This note is directed to the network community at large, rather than 
specifically to the old FTP committee, because I don’t believe that 
the FTP committee membership includes all the individuals who have 
contributed to the current state of FTP design. Nevertheless, it is 
intended that the meeting proceed from the current state, rather than 
bringing new members up-to-speed. Prospective attendees should 
therefore be familiar with at least the following documents: 


RFC 354 
RFC 385 
RFC 414 
RFC 418 
RFC 438 


Anyone wishing to attend this meeting should contact Alex McKenzie 
(NIC Ident aam) at BBN, 50 Moulton Street, Cambridge, Mass. 02138. 
My telephone number is: 

(617) 491-1850 ext.441 
When there is some indication of the number of individuals planning 


to attend, a meeting room will be reserved and more specific 
information will be directed to attendees. 
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PROPOSED FILE TRANSFER PROTOCOL 


INTRODUCTION 


ILa 


II 


The File Transfer Protocol (FTP) is a protocol for file transfer 
between HOSTs (including terminal IMPs), on the ARPA Computer Network 
(ARPANET). The primary function of FTP is to transfer files 
efficiently and reliably among HOSTs and to allow the convenient use 
of remote file storage capabilities. 


The objectives of FTP are 1) to promote sharing of files (computer 
programs and/or data), 2) to encourage indirect or implicit (via 
programs) use of remote computers, 3) to shield a user from 
variations in file storage systems among HOSTs, and 4) to transfer 
data reliably and efficiently. FTP, though usable directly by a user 
at a terminal, is designed mainly for use by programs. 


The attempt in this specification is to satisfy the diverse needs of 
users of maxi-HOSTs, mini-HOSTs, TIPs, and the Datacomputer, with a 
simple, elegant, and easily implemented protocol design. 
This paper assumes knowledge of the following protocols: 

1) The HOST-HOST Protocol (NIC #8246) 

2) The Initial Connection Protocol (NIC #7101) 

3) The TELNET Protocol (NWG/RFC #318, NIC #9348) 

DISCUSSION 

In this section, the terminology and the FTP model are discussed. 


The terms defined in this section are only those that have special 
significance in FTP. 


.A Terminology 


ASCII The USASCII character set as defined in NIC 
#7104. In FTP, ASCII characters are defined to 
be the lower half of an eight bit code set (i.e., 
the most significant bit is zero). 


access controls Access controls define users’ access privileges 
to the use of a system, and to the files in that 
system. Access controls are necessary to prevent 
unauthorized or accidental use of files. It is 
the prerogative of a server-FTP process to 
provide access controls. 
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byte size 


data connection 


data socket 


EOF 


EOR 


error recovery 


FTP commands 


file 


mode 


NVT 
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The byte size specified for the transfer od data. 
The data connection is opened with this byte 
size. Data connection byte size is not 
necessarily the byte size in which data is to be 
stored in a system, and may not be related to the 
structure of data. 


A simplex connection over which data is 
transferred, in a specified byte size, mode and 
type. The data transferred may be a part of a 
file, an entire file or a number of files. The 
data connection may be in either direction 
(server-to-user or user-to-server). 


The socket on which a User-FTP process "listens" 
for a data connection. 


The end-of-file condition that defines the end of 
a file being transferred. 


The end-of-record condition that defines the end 
of a record being transferred. 


A procedure that allows a user to recover from 
certain errors such as failure of either HOST 
system or transfer process. In FTP, error 
recovery may involve restarting a file transfer 
at a given checkpoint. 


A set of commands that comprise the control 
information flowing from the user-FTP to the 
server-FTP process. 


An ordered set of computer data (including 
programs) of arbitrary length uniquely identified 
by a pathname. 


The mode in which data is to be transferred via 
the data connection. The mode defines the data 
format including EOR and EOF. The transfer modes 
defined in FTP are described in Section III.C. 


The Network Virtual Terminal as defined in the 
ARPANET TELNET Protocol. 
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NVFS 


pathname 


record 


reply 


server-FTP process 


server site 


server-TELNET 


TELNET connections 
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The Network Virtual File System. A concept which 
defines a standard network file system with 
standard commands and pathname conventions. FTP 
only partially embraces the NVFS concept at this 
time. 


Pathname is defined to be the character string 
which must be input to a file system by a user in 
order to identify a file. Pathname normally 
contains device and/or directory names, and file 
name specification. FTP does not yet specify a 
standard pathname convention. Each user must 
follow the file naming conventions of the file 
systems he wishes to use. 


A sequential file may be structured as a number 
of contiguous parts called records. Record 
structures are supported by FTP but are not 
mandatory. 


A reply is an acknowledgement (positive or 
negative) sent from server to user via the TELNET 
connections in response to FTP commands. The 
general form of a reply is a completion code 
(including error codes) followed by an ASCII text 
string. The codes are for use by programs and 
the text is for human users. 


A process or set of processes which perform the 
function of file transfer in cooperation with a 
user-FTP process. The server-FTP process must 
interpret and respond to user commands and 
initiate the data connection. 


A HOST site which has a server-FTP process. 


A TELNET process which listens on a specified 
socket for an ICP initiated by a user-TELNET, and 
performs in accordance with the ARPANET TELNET 
Protocol. 


The full-duplex communication path between a 
user-TELNET and a server-TELNET. The TELNET 
connections are established via the standard 
ARPANET Initial Connection Protocol (ICP). 
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type The data representation type used for data 
transfer and storage. Type implies certain 
transformations between the time of data storage 
and data transfer. The representation types 
defined in FTP are described in Section III.B. 


user A process on behalf of a human being or a human 
being wishing to obtain file transfer service. 


user site A HOST site satisfying any of the following 
conditions: 1) The site where a user is located, 
2) a site where a user-FTP process is located, 3) 
a site to which a data connection is made by a 
server. In the normal case, the sites defined by 
1, 2, and 3 are the same site, but nothing in FTP 
requires that this be so. 


user-FTP process A process or set of processes which perform the 
function of file transfer in cooperation with a 
server-FTP process. The user-FTP process 1) 
initiates the ICP (via a user-TELNET), 2) 
initiates FTP commands and 3) "listens" on the 
data socket for the data connection. In some 
obvious cases (use from TIPs and other mini- 
HOSTs) a user-FTP process will be subsumed under 
the term "user". 


user-TELNET A TELNET process which initiates an ICP to a 
specified server-TELNET socket, and performs in 
accordance with the ARPANET TELNET protocol. 


II.B The FTP Model 


With the above definitions in mind, the following model (shown in 
Figure 1) may be diagramed for an FTP service. 


In the model described in Figure 1, the user-TELNET initiates the 
TELNET connections. Standard FTP commands are then generated by the 
user and transmitted to the server site via the TELNET connections. 
FTP commands are in ASCII, in accordance with NVT conventions and the 
TELNET protocol. Note that commands may be initiated by the user 
directly through the user-TELNET or via a user-FTP process. Standard 
replies are sent from the server to the user in response to the 
commands over the TELNET connections. 
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The FTP commands specify the parameters for the data connection (data 
socket, byte size, transfer mode, representation type, and format) 
and the nature of file system operation (store, retrieve, append, 
delete, etc.). The user-FTP process or its designate should "listen" 
on the specified data socket, and it is the server’s responsibility 
to initiate the data connection and data transfer in accordance with 
the specified data connection parameters. It should be noted that 
the data socket need not be in the same HOST that initiates the FTP 
commands via the TELNET connections, but the user or his user-FTP 
process must ensure a "listen" on the specified data socket. A 
practical example of such file transfer to third HOSTs is a maxi-HOST 
user (who may actually be a TIP user) wishing to transmit a file to 
or from an I/O device attached to a TIP. It should also be noted 
that two data connections, one for send and the other for receive, 
may exist simultaneously. 


TELNET 
Connections 
+----- + +------- + +------ + +------ + +------- + +----- + 
| File|<->|Server-|<->| Server |<---------- [User |<->|User-  |<->|File | 
[Sys | |FTP | |TELNET| FTP Cmds |TELNET| | FTP | |Sys- | 
| -tem| Process | | BE SRSRSSSS > | | Process | tem | 
+----— + +------ +ETP“Replies+s-—-=> + +----— + 
| | | | 
| |<------------------------------- >|Data 
| | Data Connection (s) | Socket | 
+------- + +------— + 
+------ + 
| | 
| USER | 
| | 
+------ + 
Notes: 1. The data connection may be in either direction. 


2. The data connection need not exist all of the time. 

3. The distinctions between user-FTP and user-TELNET, and 
between server-FTP and server-TELNET may not be as 
clear-cut as shown above. For example, a user-TELNET may 
be directly driven by the user. 


FIGURE 1 Model for FTP Use 
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The protocol requires that the TELNET connections be open while data 
transfer is in progress. It is the responsibility of the user to 
close the TELNET connections when finished using the FTP service. 
The server may abort data transfer if the TELNET connections are 
closed. 


III. DATA TRANSFER FUNCTIONS 


Data and files are transferred only via the data connection. The 
transfer of data is governed by FTP data transfer commands received 
on the TELNET connections. The data transfer functions include 
establishing the data connection to the specified data socket in the 
specified HOST (using the specified byte size), transmitting and 
receiving data in the specified representation type and transfer 
mode, handling EOR and EOF conditions, and error recovery (where 
applicable). 


III.A Establishing Data Connection 


The user site shall "listen" on the specified data socket, prior to 
sending a transfer request command. The FTP request command 
determines the direction of data transfer, and the socket number (odd 
or even) which is to be used in establishing the data connection. 
The server on receiving the appropriate store or retrieve request 
shall initiate the data connection to the specified user data socket 
in the specified byte size (default byte size is 8 bits), and senda 
reply indicating that file transfer may proceed. Prior to this 
reply, the server should send a reply indicating the server socket 
for the data connection. The user may use this server socket 
information to ensure the security of his data transfer. The server 
may send this reply either before or after initiating the data 
connection. 


The byte size for the data connection is specified by the BYTE 
command. It is not required by the protocol that servers accept all 
possible byte sizes. The use of various byte sizes is for efficiency 
in data transfer and servers may implement only those byte sizes for 
which their data transfer is efficient. It is, however, required 
that servers implement at least the byte size of 8 bits. 


After the data transfer is completed, it is the server’s 
responsibility to close the data connection, except when the user is 
sending the data. In stream mode the sender must close the data 
connection to indicate EOF, i.e., completion of the transfer. 
Closing the connection is a server option except under the following 
conditions: 
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1) The server receives an abort command from the user. 

2) The socket or the byte size specification is changed by the 
user. 

3) The TELNET connections are closed. 

4) An irrecoverable error condition occurs. 


It should be noted that if none of the above conditions occur it is 
possible to maintain two simultaneous data connections, for send and 
receive. 


III.B Data Representation and Storage 


Data is transferred from a storage device in sending HOST to a 
storage device in receiving HOST. Often it is necessary to perform 
certain transformations on the data because data storage representa- 
tions in the two systems are different. For example, NVTI-ASCII has 
different data storage representations in different systems. PDP-10’ 
s generally store NVT-ASCII as five 7-bit ASCII characters, left- 
justified in a 36-bit word. 360’s store NVT-ASCII as 8-bit EBCDIC 
codes. Multics stores NVT-ASCII as four 9-bit characters in a 36-bit 
word. It may be desirable to convert characters into the standard 
NVT-ASCII representation when transmitting text between dissimilar 
systems. The sending and receiving sites would have to perform the 
necessary transformations between the standard representation and 
their internal representations. 


A different problem in representation arises when transmitting binary 
data (not character codes) between HOST systems with different word 
lengths. It is not always clear how the sender should send data, and 
the receiver store it. For example, when transmitting 32-bit bytes 
from a 32-bit word-length system to a 36-bit word-length system, it 
may be desirable (for reasons of efficiency and usefulness) to store 
the 32-bit bytes right-justified in a 36-bit word in the latter sys- 
tem. In any case, the user should have the option of specifying data 
representation and transformation functions. It should be noted that 
FTP provides for very limited data type representations. Transforma- 
tions desired beyond this limited capability should be performed by 
the user directly or via the use of the Data Reconfiguration (DRS, 
RFC #138, NIC #6715). Additional representation types may be defined 
later if there is a demonstrable need. 


Data representations are handled in FTP by a user specifying a 
representation type. The type may also imply a transfer byte size. 
For example, in ASCII representation, the transfer byte size should 
be 8 bits, and any other byte size specification will result in 
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cancellation of the transfer request. In image and Local Byte 
representations any byte size is possible. The following data 
representation types are currently defined in FTP: 


1. ASCII 
2. EBCDIC 
3. Image 


4. Local Byte 


McKenzie 


The sender converts data from its internal character 
representation to the standard NVT ASCII form. The 
receiver converts the data from the standard form to 
its own internal form. The data is transferred in 
the standard form. The transfer byte size must be 8 
bits. This type would be used for transfer of text 
files. This is the default type, and it is recom- 
mended that this type be implemented by all. 


The sender transfers data using the EBCDIC character 
code and 8-bit transfer byte size. This type may be 
used for efficient transfer of EBCDIC files between 
systems which use EBCDIC for their internal character 
representation. 


The sender transforms data from contiguous bits to 
bytes for transfer. The receiver transforms the 
bytes into bits, storing them contiguously indepen- 
dent of the byte size chosen for data transfer. With 
record structure and block mode, the server might 
need to pad each record for convenient storage. This 
padding is allowed at the end of a record, and should 
be remembered by the server so it will be stripped 
off when the file is retrieved by the user. The pad- 
ding transformation should be well publicized by the 
server in case the user processes his file at the 
server site. Typical uses for the Image type are 
transfer of executable programs between like 
machines, and transfer of binary (non-text) data. It 
is recommended that this type be implemented by all 
for some byte size, preferably including the 8 bit 
byte size. 


This representation allows for efficient storage, 
use, and retrieval of data. The manner in which data 
is to be transformed depends on the byte size for 
data transfer, and the particular HOST being used. 
The transformation scheme for different byte size is 
to be well publicized by all server sites. This 
transformation shall be invertible (i.e., if a file 
is stored using a certain transfer byte size, an 
identical file must be retrievable using the same 
byte size and representation type). It is the user’s 
responsibility to keep track of the representation 
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type and byte size used for his transfer. Typical 
uses of the Local Byte type are in efficient storage 
and retrieval of files, and transfer of structured 
binary data. This type may be identical to the Image 
type for byte size which are integral multiples of or 
factors of the computer word length. 


Representation type may also be affected by another attribute, the 
format. For example, some printers can use ASA (Fortran) vertical 
format control procedures to transform printed data of type ASCII or 
EBCDIC. Currently format may take one of two values. 


1. Unformatted The representation type as specified is unaffected by 
any format transformations. This is the default 
value. 


2. Printfile The server is to transform data of either ASCII or 
EBCDIC type in accordance with ASA (Fortran) vertical 
format control standards. The data is to be 
transferred in 8-bit bytes. 


A discussion of the ASA vertical format control appears in NWG/RFC 
189, Appendix C, and in Communications of the ACM, Vol. 7, No. 10, p. 
606, October 1964. According to the ASA vertical format control 
standards, the first character of a formatted record is not printed 
but determines vertical spacing as follow: 


Character Vertical Spacing before printing 
Blank One line 
0 Two lines 
1 To first line of the next page 
+ No advance 


In addition to the above four, there are more characters (defined in 
Appendix C, RFC 189) which represent an IBM extension to the ASA 
standard. 


It should be noted that a serving host need not accept all represen- 
tation types and/or byte sizes, but it must inform the user request- 
ing an unacceptable type or size of this fact by sending an appropri- 
ate reply. 


III.C. File Structure and Transfer Modes 
The only file structures supported directly in FTP at the present 


time are record structures. However, the use of record structures is 
not mandatory. A user with no record structure in his file should be 
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able to store and retrieve his file at any HOST. A user wishing to 
transmit a record structured file must send the appropriate FTP 

’ STRU’ command (the default assumption is no record structure). A 
serving HOST need not accept record structures, but it must inform 
the user of this fact by sending an appropriate reply. Any record 
structure information in the data stream may subsequently be dis- 
carded by the receiver. 


All data transfers must end with an EOF. The EOF is defined by the 
data transfer mode. For files that have record structures, an EOR is 
also defined by the transfer mode. Only the transfer modes and 
representation type combinations that have EOR defined may be used 
for transfer of files with record structures. Records may be of zero 
length but they must be contained in file boundaries. The relation- 
ship between files and records is hierarchical but an EOF does not 
imply an EOR. 


The following data transfer modes are defined in FTP: 


1. Stream The file is transmitted as a stream of bytes of the 
specified byte size. The EOF is signaled by closing 
the data connection. Any representation type and 
byte size may be used in the stream mode with file 
structure, but use of record structure limits the 
type to ASCII or EBCDIC with or without Printfile 
format. The convention is that the ASCII character 
CR (Carriage Return, Code 15 (octal)) followed by LF 
(Line Feed, Code 12 (octal)) indicates an EOR for 
ASCII representation type, and the EBCDIC character 
NL (New Line, Code 15 (hex)) indicates an EOR for 
EBCDIC type. This is the default mode, and it is 
recommended that this mode be implemented by all. 


2. Text The file is ASCII text transmitted as a sequence of 
8-bit bytes in the ASCII representation type, and 
optional Printfile format. Record structures are 
allowed in this mode. The EOR and EOF are defined by 
the presence of special "TELNET-control" codes (,ost 
Significant bit set to one) in the data stream. The 


EOR code is 192 (octal 300, hex CO). The EOF code is 
193 (octal 301, hex Cl). The byte size for transfer 
is 8 bits. 


(For ASCII type, text and stream modes are almost identical.) 
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Comparing the two, the advantages of "stream" mode are: 
1) The receiver need not scan the incoming bytes. 
2) It is usable with all data types. 


and the disadvantages are: 

1) Closing the data connection under error conditions can be 
misconstrued as an EOF in stream mode when in fact the data 
transfer was interrupted. In text mode the EOF is sent expli- 
citly. 


2) If record structure is specified in stream mode then CRLF 
implies EOR, and in order for CRLF to be sent as valid data it 
must be transformed, e.g., into CR NUL LF or LF CR. 


3. Block The file is transmitted as a series of data blocks 
preceded by one or more header bytes. The header 
bytes contain a count field, and descriptor code. 
The count field indicates the total length of the 
data block in bytes, thus marking the beginning of 
the next data block (there are no filler bits). The 
descriptor code defines last file block (EOF), last 
record block (EOR), restart marker (see Section 
TII.D), or suspect data (i.e., the data being 
transferred is suspected of errors and is not reli- 
able). Record structures are allowed in this mode, 
and any representation type or byte size may be used. 


The header consists of the smallest integral number 
of bytes whose length is greater than or equal to 24 
bits. Only the _least_ significant 24 bits (right- 
justified) of header shall have information; the 
remaining most significant bits are "don’t care" 
bits. Of the 24 bits of header information, the 16 
low order bits shall represent byte count, and the 8 
high order bits shall represent descriptor codes as 
shown below. 


Integral data bytes >= 24 
+--------------- +--------------- +-------------- + 
| Don’t care Descriptor 


| 0 to 237 bits 8 bits 16 bits | 
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The following descriptor codes are assigned: 


Code Meaning 
0 An ordinary block of data. 
1 End of data block is EOR. 
2 End of data block is EOF. 
3 Suspected errors in data block. 
4 Data block is a restart marker. 


In the use of block mode it is possible for two or 
more conditions requiring different descriptor codes 
(suspected errors and either end of record or end of 
file) to exist simultaneously. Such a possibility 
may be handled by sending a separate EOR or EOF block 
with a zero byte count. (This is allowed by the pro- 
tocol.) 


The restart marker is embedded in the data stream as 
an integral number of 8-bit bytes (representing 
printable ASCII characters) right-justified in an 
integral number of data bytes greater than 8 bits. 
For example if the byte size is 7 bits, the restart 
marker byte would be one byte right-justified per two 
7-bit bytes as shown below: 


Two 7-bit bytes 
4+---------- 4------------ + 
Marker Char | 

8 bits | 


For byte size of 16 bits or more, two or more marker 
bytes shall be packed right-justified. The end of 
the marker may be delimited by the character SP (code 
32.). If marker characters do not exactly fit an 
integral byte, the unused character slots should con- 
tain the ASCII character SP (code 32.). For example, 
to transmit a six character marker in a 36-bit byte 
size, the following three 36-bit bytes would be sent: 
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toss aa Peete 55 sae + 
| Don’t care | Descriptor | | 
| 12 bits | code=4 | Byte count=2 | 
Pe E CA EEE ha ae ee + 
toa ato 555-5 | a + SSSR SSS PSS RSS sSoS + 
| | Marker | Marker | Marker | Marker | 
| | 8 bits | 8 bits | 8 bits | 8 bits | 
toss t5 555-7 t--------- t----- 7 t--------— + 
toa a ato 555-5 t--------- Fantasmi phan + 
| | Marker | Marker | SP | SP | 
| | 8 bits | 8 bits | 8 bits | 8 bits | 
E t--------- Firtina Paremmin + 


4. Hasp 


The file is transmitted as a sequence of 8-bit bytes 
in the standard Hasp-compressed data format (document 
to be issued by Bob Braden, UCLA). This mode 
achieves considerable compression of data for print 
files. Record structures are allowed in the Hasp 
mode. 


The following matrix summarizes the legal combinations of file 
transfer parameters. The decimal integers represent legal byte sizes 
for each particular STRU-MODE-TYPE-FORM grouping absence of a number 
implies illegality. Note that HASP mode is not included since it has 
never been defined. 


STRU F | R 
4------------------------------- 4+----- 4+----- 4+------ + 
TYPE |\ MODE | | | | 
\ 
\ S T B S T B 

| FORM +-------- +----- +--------- +----- +----- +------ + 
a j| u | 8a |8 |: a 8g] 8 | 
| +-------—- +----- +--------- +----—- +----- +-----—- + 
Woes. 8 all). 8 e e E calf 8? a Wl. 8s, 4 
----+------4-------- 4+----- 4+--------- 4+----- 4+----- 4+------ + 
E | u | 8 | | 8 | 8 | | 8s | 
| +-------—- +----- +--------- +----- +----- +-----—- + 

Lh. BP E = | 8& |8| | 8|] 
----+------ 4+-------- 4+----- 4+--------- 4+----- 4+----- 4+------ + 
I | u [| 1-255 | | 1-255 | | |1-255 | 
----+------ 4+-------- 4+----- 4+--------- 4+----- 4+----- 4+------ + 
Lo | u | 1-255 | | 1-255 | | |1-255 | 
----+------ 4+-------- 4+----- 4+--------- 4+----- 4+----- 4+------ + 
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III.D Error Recovery and Restart 


There is no provision for detecting bits lost or scrambled in data 
transfer. This issue is perhaps handled best at the NCP level where 
it benefits most users. However, a restart procedure is provided to 
protect user from system failures (such as failure of either HOST, 
FTP-process, or the IMP subnet). 


The restart procedure is defined only for the block mode of data 
transfer. It requires the sender of data to insert a special marker 
code in the data stream with some marker information. The marker 
information has meaning only to the sender, but must consist of 
printable ASCII characters. The printable ASCII characters are 
defined to be octal codes 41 through 176 (i.e., not including codes 0 
through 37 and the characters SP and DEL). The marker could 
represent a bit-count, a record-count, or any other information by 
which a system may identify a data checkpoint. The receiver of data, 
if it implements the restart procedure, would then mark the 
corresponding position of this marker in the receiving system, and 
return this information to the user. 


In the event of a system failure, the user can restart the data 
transfer by identifying the marker point with the FTP restart pro- 
cedure. The following examples illustrate the use of the restart 
procedure. 


Ty When server is the sender of data, the server-FTP process inserts 
an appropriate marker block in the data stream at a convenient 
data point. The user-FTP process, receiving the data, marks the 
corresponding data point in its file system and conveys the last 
known sender and receiver marker information to the user. In the 
event of system failure, the user or user-FTP process restarts 
the server at the last server marker by sending a restart command 
with the server's marker code as its argument. The restart com- 
mand is transmitted over the TELNET connection and is immediately 
followed by the command (such as store or retrieve) which was 
being executed when the system failure occurred. 


2. When user is the sender of data, the user-FTP process inserts the 
appropriate marker block in the data stream. The server-FTP pro- 
cess, receiving the data, marks the corresponding data point in 
its file system. The server does not store this marker but con- 
veys the last known sender and receiver marker information to the 
user over the TELNET connections by appropriate reply codes. The 
user or the user-FTP process then restarts transfer in a manner 
identical to that described in the first example. 
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IV. FILE TRANSFER FUNCTIONS 


The TELNET connections on which FTP commands and replies are 
transmitted are initiated by the user-FTP process via an ICP toa 
standard server socket. FTP commands are then transmitted from user 
to server, and replies are transmitted from server to user. The user 
file transfer functions involve sending the FTP commands, interpret- 
ing the replies received and transferring data over the data connec- 
tion in the specified manner. The server file transfer functions 
involve accepting and interpreting FTP commands, sending replies, 
setting up the data connection, and transferring data. 
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IV.A FTP Commands 


FTP commands are ASCII strings terminated by the ASCII character 
sequence CRLF (Carriage Return followed by Line Feed). The command 
codes themselves are ASCII alphabetic characters terminated by the 
ASCII character ’space’ (octal code 40). For convenience, the com- 
mand codes are defined to be four (or less) ASCII alphanumeric char- 
acters (including both upper and lower case alphabetic characters). 
The command codes and the semantics of commands are described in this 
section, but the detailed syntax of commands is specified in Section 
V.B, the reply sequences are discussed in Section V.C, and scenarios 
illustrating the use of commands are provided in Section V.D. 


FTP commands may be partitioned as those specifying access-control 


identifiers, data transfer parameters, or FTP service requests. Cer- 
tain commands (such as ABOR, STAT, BYE) may be sent over the TELNET 
connections while a data transfer is in progress. Some servers may 


not be able to monitor the TELNET and data connections simultane- 
ously, in which case these commands should be preceded by a TELNET 
SYNC to awaken the server. (For other servers this may not be neces- 
sary and the SYNC will be ignored.) 


IV.A.1 Access Control Commands 


The following commands specify access control identifiers (command 
codes are shown in parentheses). 


User name (USER) - The argument field is an ASCII string identify- 
ing the user. The user identification is that which is required 
by the server for access to its file system. This command will 
normally be the first command transmitted by the user after the 
TELNET connections are made (some servers may require this). 
Additional identification information in the form of a password 
and/or an account command may also be required by some servers. 
Servers may allow a new USER command to be entered at any point in 
order to change the accounting information. All parameters are 
unchanged and any file transfer in progress is completed under the 
old account. 


Password (PASS) - The argument field is an ASCII string identify- 
ing the user’s password. This command must be immediatly preceded 
by the user name command, and, for some sites, completes the user’ 
s identification for access control. Since password information 
is quite sensitive, it is desirable in general to "mask" it or 
suppress type out. It appears that the server has no foolproof 
way to achieve this. It is therefore the responsibility of the 
user-FTP process to hide the sensitive password information. 
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Account (ACCT) - The argument field is an ASCII string identifying 
the user’s account. The command is not necessarily related to the 
USER command, as some sites may require an account for login and 
others only for specific access, such as storing files. In the 
latter case the command may arrive at any time. There are two 
reply codes to differentiate these cases for the automaton: When 
account information is required for login and the server receives 
another command which he buffers, the legal response is reply code 
331 when an account is required for a specific transfer requested, 
the reply code 433 is returned and the request command is flushed. 


Reinitialize (REIN) - This command terminates a USER, flushing all 
I/O and account information, except to allow any transfer in pro- 
gress to be completed. All parameters are reset to the default 
setting and the TELNET connection is left open. A USER command is 
expected to follow. 


Logout (BYE) - This command terminates a USER and if file transfer 
is not in progress, closes the TELNET connection. If file 
transfer is in progress, the connection will remain open for 
result response and will then close. For "hot card-reader" mode 
the REIN command should be used instead. 


An unexpected close on the TELNET connection will cause the server 
to take the effective action of an abort (ABOR) and a logout 
(BYE) . 


IV.A.2 Transfer Parameter Commands 


All data transfer parameters have default values, and the commands 
specifying data transfer parameters are required only if the default 
parameter values are to be changed. The default value is the last 
specified value, or if no value has been specified, the standard 
default value as stated here. This implies that the server must 
"remember" the applicable default values. The commands may be in any 
order except that they must precede the FTP service request. The 
following commands specify data transfer parameters 


Byte size (BYTE) - The argument is an ASCII-represented decimal 
integer (1 through 255), specifying the byte size for the data 
connection. The default byte size is 8 bits. The byte size is 
always 8 bits in the ASCII and EBCDIC representation types. A 
server may reject specific byte size/type combinations by sending 
an error reply code in response to a transfer request command. 


Data socket (SOCK) - The argument is a HOST-socket specification 


for the data socket to be used in data connection. There may be 
two data sockets, one from server to user and the other for user 
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to server data transfer. An odd socket number defines a send 
socket and an even socket number defines a receive socket. The 
default HOST is the user HOST to which TELNET connections are 
made. The default data sockets are (U+4) and (U+5) where U is the 
socket number used in the TELNET ICP and the TELNET connections 
are on sockets (U+2) and (U+3). 


Listen (LSTN) - The argument is a single ASCII character code to 
specify the direction of the socket that the server must allocate 
for use as a data connection. The server is to "listen" on the 
allocated socket when an appropriate transfer command is given. 
The following codes are assigned: 


S - send 
R - receive 
Representation Type (TYPE) - The argument is a single ASCII char- 


acter code specifying the representation types described in Sec- 
tion III.B. The following codes are assigned for type: 


A - ASCII 

I - Image 

L - Local Byte 
E - EBCDIC 


The default representation type is ASCII. 


Format (FORM) - The argument is a single ASCII character code 
specifying the formats described in Section III.B. The following 
codes are assigned for format: 


U - Unformatted 
P - Printfile 


The default format is Unformatted. 
File Structure (STRU) - The argument is a single ASCII character 
code specifying file structure described in Section III.C. The 


following codes are assigned for structure: 


F -— File (no ecord structure) 
R -— Record structure 


The default structure is File (ie. no records). 
Transfer Mode (MODE) - The argument is a single ASCII character 


code specifying the data transfer modes described in Section 
III.C. The following codes are assigned for transfer modes: 
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Stream (bytes, close is EOF) 

- Block (header with descriptor and count) 
Text (TELNET control code for EOR, EOF) 

- Hasp (specially formatted compressed data) 


THUN 
| 


The default transfer mode is Stream. 
IV.A.3 FTP Service Commands 


The FTP service commands define the file transfer or the file system 
function requested by the user. The argument of an FTP service com- 
mand will normally be a pathname. The syntax of pathnames must con- 
form to server site conventions (with standard defaults applicable), 
except that ASCII characters must be used (in conformance with the 
TELNET Protocol). The suggested default handling is to use the last 
specified device, directory or file name, or the standard default 
defined for local users. The command may be in any order except that 
a "rename from" command, must be followed by a "rename to" command, 
and some servers may require an "allocate" command before a "store" 
command. The data, when transferred in response to FTP service 
commands, shall always be sent over the data connection. The follow- 
ing commands specify FTP service requests: 


Retrieve (RETR) - This command achieves the transfer of a copy of 
the file specified in the pathname, from server to user site. The 
status and contents of the file at the server site shall be unaf- 
fected. 


Store (STOR) - This command achieves the transfer of a copy of a 
file from user to server site. If the file specified in the path- 
name exists at the server site, then its contents shall be 
replaced by the contents of the file being transferred. A new 
file is created at the server site if the file specified in the 
pathname does not already exist. 


Append (with create) (APPE) - This command achieves the transfer 
of data from using to serving site. If the file specified in the 
pathname exists at the server site, then the data transferred 
shall be appended to that file, otherwise the file specified in 
the pathname shall be created at the server site. 


Allocate (ALLO) - This command may required by some servers to 
reserve sufficient storage to accommodate the new file to be 
transferred. The argument field shall be a decimal integer 
representing the number of bytes (of size specified by the byte 
size command) of storage to be reserved for the file. This 
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command shall be followed by a store or append command. The ALLO 
command should be treated as a NO-OP (no operation) by those 
servers which do not require that the maximum size of the file be 
declared beforehand. 


Restart (REST) - The argument field represents the server marker 
at which file transfer is to be restarted. This command does not 
cause file transfer but "spaces" over the file to the specified 
data checkpoint. This command shall be immediately followed by 
the appropriate FTP service command which shall cause file 
transfer to resume. 


Rename from - (RNFR) - This command specifies the file which is to 
be renamed. This command must be immediately followed by a 
"rename to" command specifying the new file pathname. 


Rename to (RNTO) - This command specifies the new pathname of the 
file specified in the immediately preceding "rename from" command. 
Together the two commands cause a file to be renamed. 


Abort (ABOR) - This command indicates to the server to abort the 
previous FTP service command and any associated transfer of data. 
The abort command should be preceded by the TELNET SYNCH condition 
(indicated by the combination of the DATA MARK and the INS). No 
action is to be taken if the previous command has been completed 
(including data transfer). The TELNET connections are not to be 
closed by the server, but the data connection may be closed. An 
appropriate reply should be sent by the server. 


Delete (DELE) - This command causes the file specified in the 
pathname to be deleted at the server site. If an extra level of 
protection is desired (such as the query, "Do you really wish to 
delete?"), it should be provided by the user-FTP process. 


List (LIST) - This command causes a list to be sent from server to 
user site. If the pathname specifies a directory, the server 
should transfer a list of files in the specified directory. If 


the pathname specifies a file then server should send current 
information on the file. A null argument implies the user’s 
current working or default directory. The data transfer is over 
the data connection in type ASCII or type EBCDIC. (It is the user 
's responsibility to ensure the correct parameters.) 


NList (NLST) - This command causes a directory listing to be sent 
from server to user site. The pathname should specify a directory 
and the server will return a stream of names of files and no other 
information. The data will be transferred in ASCII or EBCDIC type 
over the data connection as valid pathname strings separated by 
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CRLF. This command will allow automatic copying of an entire 
directory when used with the appropriate transfer commands. 


Status (STAT) - This command shall cause a status response to be 
sent over the TELNET connection in form of a reply. The command 
may be sent during a file transfer (preceded by a TELNET SYNC) in 
which case the server will respond with the status of the opera- 
tion in progress, or it may be sent between file transfers. In 
the latter case the command may have an argument field such as a 
pathname. If the argument is a pathname, the command is analogous 
to the "list" command except that data shall be transferred in 
ASCII on the TELNET connection. If a partial pathname is given, 
the server may respond with a list of file names or attributes 
associated with that specification. If no argument is given, the 
server should return general status information about the server 
FTP process. This should include current values of all transfer 
parameters and the status of connections. 


Help (HELP) - This command shall cause the server to send helpful 
information regarding its implementation status over the TELNET 
connection to the user. The command may take an argument (e.g. 
any command name) and return more specific information as a 
response. The reply is type 100, general system status. It is 
suggested that HELP be allowed before entering a USER command. 


Mail File (MLFL) - The intent of this command is to enable a user 
site to mail data (in form of a file) to another user at the 
server site. It should be noted that the files to be mailed are 


transmitted via the data connection in ASCII or EBCDIC type. (It 
is the user’s responsibility to ensure that the type is correct.) 
These files should be appended to the destination user’s mail by 
the server in accordance with serving HOST mail conventions. The 
mail may be marked as sent from the particular using HOST and the 
user specified by the ’USER’ command. The argument field may con- 
tain one or more system or NIC idents (it is recommended that mul- 
tiple ident be allowed so the same mail can easily be sent to 
several users), or it may be empty. If the argument field is 
empty or blank (one or more spaces), then the mail is destined for 
a printer or other designated place for site mail. A NIC ident 
refers to the standard identification described in the NIC Direc- 
tory of Network Participants. A serving host may keep a table 
mapping NIC indents into system idents, although NIC idents are 
not required in the implementation. A system ident is the user’s 
normal identification at the serving host. The use of system 
idents would allow a network user to send mail to other users who 
do not have NIC identification but whose system ident is known. 
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Mail (MAIL) - This command allows a user to send mail that is not 
in a file over the TELNET connection. The argument field may con- 
tain one or more system or NIC idents, or it may be empty. The 
idents are defined as above for the MLFL command. After the 
‘MAIL’ command is received, the server is to treat the following 
lines as text of the mail sent by the user. The mail text is to 
be terminated by a line containing only a single period, that is, 
the character sequence ".CRLF" in a new line. It is suggested 
that a modest volume of mail service should be free; i.e., it may 
be entered before a USER command. 


IV.A.4 Miscellaneous Commands 


IV. 


NoOP (NOOP) - This command does not affect any parameters or pre- 
viously entered command. The server simply sends a no-op reply. 


Quote (QUOT) - This command allows the user to talk directly to 
the FTP-server. After parsing this command, the user-FTP process 
will pass without examination all succeeding liners until the NQUO 
command is received. Between these two commands the server will 
respond appropriately to his implementation and the user’s 
requests. 


NoQuote (NQUO) - This command returns the user and server 
processes to normal interactive mode. Both QUOT and NQUO have 
reply codes to be sent by th server process to the user process to 
ensure agreement on the current mode. 


The quote commands provide a convenient method of testing server- 
implemented experimental commands. The names of the latter should 


begin with an X, and can be listed in the system HELP reply. It 


should be noted that the official command set is expandable; sugges- 


tions should go first to Alexander A. McKenzie (BBN). 


B FTP Replies 


The server sends FTP replies over the TELNET connection in response 


to user FTP commands. The FTP replies constitute the acknowledgment 


or completion code (including errors). The FTP-server replies are 
formatted for human or program interpretation. Single line replies 
consist of a leading three-digit numeric code followed by a space, 
followed by a one-line text explanation of the code. For replies 
that contain several lines of text, the first line will have a lead- 
ing three-digit numeric code followed immediately by the ASCII char- 
acter "-" (Hyphen, Code 55 (octal)) and possibly some text. All 
succeeding continuation lines except the last are constrained not to 


begin with three digits; the last line must repeat the numeric code 


of the first line and be followed immediately by a space. 
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For example: 


100-First Line 
Continuation Line 
Another Line 

100 Last Line 


The numeric codes are assigned by groups and for ease of interpreta- 


tion by 
the RJE 


programs in a manner consistent with other protocols such as 
protocol. The three digits of the code are to be interpreted 


as follows: 


a) The first digit specifies type of response as indicated below: 


000 


1xx 


2XX 


3xx 


4xx 


5xxX 


6xx- 


McKenzie 


These replies are purely informative and constitute neither a 
positive nor a negative acknowledgment. 


Informative replies to status inquiries. These constitute a 
positive acknowledgment to the status command. 


Positive acknowledgment of previous command or other success- 
ful action. 


Incomplete information. Activity cannot proceed without 
further specification and input. 


Unsuccessful reply. The request is correctly specified but 
the server is unsuccessful in correctly fulfilling it. 


Incorrect or illegal command. The command or its parameters 
were invalid or incomplete from a syntactic viewpoint, or the 
command is inconsistent with a previous command. The command 


in question has been completely ignored. 


9xx Reserved for future expansion. 
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The 


000 
010 
030 
050 
100 
110 
150 
151 
200 
201 
202 
230 
231 
232 
233 
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b) The second digit specifies the general category to which the 


response refers: 


x00-x29 General purpose replies, not assignable to other 


categories. 
x30 Primary access. Informative replies to the "log-on" attempt. 
x40 Secondary access. The primary server is commenting on its 


ability to access a secondary service. 
x5x FTP results 
x6x RJE results. 


x7x-x9x Reserved for future expansion. 


c) The final digit specifies a particular message type. Since the 


code is designed for an automation process to interpret, it is 
not necessary for every variation of a reply to have a unique 
number. Only the basic meaning of replies need have unique 


numbers. The text of a reply can explain the specific reason for 


that reply to a human user. 


Each TELNET line delimited by a numeric code and CRLF (or group 
of text lines bounded by coded lines) that is sent by the server 
is intended to be a complete reply message. It should be noted 
that the text of replies is intended for a human user. Only the 
reply codes and in some instances the first line of text are 
intended for programs. 


assigned reply codes relating to FTP are: 


General information message (site, time of day, etc.). 
Message from system operator. 

Server availability information. 

FTP commentary or user information. 

System status reply. 

System busy doing... 

File status reply 

Directory listing reply. 

Last command received correctly. 

An ABORT has terminated activity, as requested. 

Abort request ignored, no activity in progress. 

User is "logged in". May proceed. 

User is “logged out". Service terminated. 

Logout command noted, will complete when transfer done. 
User is "logged out". Parameters reinitialized. 
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250 
251 


252 
253 
254 
255 


256 
300 
301 
330 
331 


350 
400 
401 
430 
431 
432 
433 
434 
435 
436 
450 
451 
452 
453 
454 
455 
456 
457 
500 
501 
502 
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FTP file transfer started correctly. 
FTP Restart-marker reply. 


Text is : MARK yyyy = mmmm 

where yyyy is user’s data stream marker (yours) 
and mmmm is server’s equivalent marker (mine) 
(Note the spaces between the markers and ’=’) 


FTP transfer completed correctly. 
Rename completed. 

Delete completed. 

FTP server data socket reply 


Text is: SOCK nnnn 
where nnnn is a decimal integer representing 
the server socket for data connection 


Mail completed. 

Connection greeting message, awaiting input. 
Current command incompleted (no CRLF for long time). 
Enter password 

Enter account (if account required as part of login 
sequence). 

Enter mail, terminate by a line with only a ’.’ 
This service not implemented. 

This service not accepting user now, goodbye. 
Log-on time or tries exceeded, goodbye. 

Log-on unsuccessful. Usre and/or password invalid. 
User not valid for this service. 


July 1972 


Cannot transfer files without valid account. Enter account. 


Log-out forced by operator action. Phone site. 

Log-out forced by system problem. 

Service shutting down, goodbye. 

FTP: File not found. 

FTP: File access denied to you. 

FTP: File transfer incomplete, data connection closed. 
FTP: File transfer incomplete, insufficient storage space. 
FTP: Cannot connect to your data socket. 

FTP: File system error not covered by other reply codes. 
FTP: Name duplication rename failed. 

FTP: Transfer parameters in error. 

Last command line completely unrecognized. 

Syntax of last command is incorrect. 

Last command incomplete, parameters missing. 


123456789012345678901234567890123456789012345678901234567890123456789012 


503 
504 
505 


Last command invalid (ignored), illegal parameter combinati 
Last command invalid, action not possible at this time. 
Last command conflicts illegally with previous command(s). 


McKenzie 


on. 
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506 Requested action not implemented by the server. 
507 Catchall error reply. 
550 Bad pathname specification (e.g., syntax error). 


V. DECLARATIVE SPECIFICATIONS 


In order to make FTP workable without needless error messages, the 
following minimum implementation is required for servers: 


TYPE -- ASCII (with 8-bit bytes) 

MODE -- Stream 
STRUCTURE -- File 

Record (with ASCII type and CRLF for EOR) 
FORM -- Unformatted 
COMMANDS -- USER, BYE, SOCK 

TYPE, BYTE, MODE, STRU, FORM 

for the default values 
RETR, STOR 
NOOP 


The initial default values for transfer parameters are: 


TYPE -- ASCII 
BYTE —- 8 
MODE -- Stream 
STRU -- File 
FORM -- Unformatted 


V.A Connections 


The server-FTP process at the server site shall "listen" on Socket 3, 
via its server-TELNET. The user or user-FTP process at the user site 
shall initiate the full-duplex TELNET connections via its user-TELNET 
performing the ARPANET standard initial connection protocol (ICP) to 
server socket 3. Servers may specify that interaction over the TEL- 
NET connections be line-at-a-time with local echo. The server is not 
obliged to provide remote echo and may ignore TELNET control charac- 
ters; he should not, however, return error response to the latter. 
All editing of command lines similarly must be local. The TELNET 
connections shall be closed by the user site upon completion of use 
and receipt of the last server reply. 


The user site must "listen" on the specified data socket or sockets 
(a send and/or a receive socket). The server site shall initiate the 
data connection using the specified data socket and byte size. The 
direction of data connection and the data socket used shall be 
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determined by the FTP service command. The server shall send a reply 
to the user indicating the server data socket so that the user may 
ensue the security of data transfer. This can be done at any time 
prior to the first transfer of data over a data connection. It 
should be emphasized that the user-FTP should not wait for a 255 
(server data socket) reply before doing the "listen", since there is 
no guarantee that the reply will arrive before the user site receives 
the initiating RFC. The security check can be done when the reply 
arrives and the data connection closed if it was made to a socket 
other than the one specified. 


The data connection shall be closed by the server site under the con- 
ditions described in Section III.A. If the server wishes to close 
the connection in modes where that is not required, it is recommended 
that the close be sent immediately after the file transfer is com- 
pleted rather than after a new transfer command is received, because 
the user or server may have to test the state of the socket before 
doing a "listen" or "init". The server should in general send a 
reply before closing the data connection to avoid problems at the 
user end, though, for reasons stated above, the user-FTP should not 
wait for the reply before doing his close. 


V.B Commands 


The commands are ASCII character strings transmitted over the TELNET 
connections as described in section IV.A. The command functions and 
semantics are described in sections IV.A.1, IV.A.2, IV.A.3, and 
IV.A.4. The command syntax is specified here. 


The commands begin with a command code followed by an argument field. 
The command codes are four or less ASCII alphabetic characters. 

Upper and lower case alphabetic characters are to be treated identi- 
cally. Thus any of the following may represent the retrieve command: 


RETR Retr tetr ReTr rETr 
This also applies to any symbols representing parameters values, such 


as A or a for ASCII TYPE. The command codes and the argument fields 
are separated by one or more spaces. 


The argument field consists of a variable length ASCII character 
string ending with the character sequence CRLF (Carriage Return 
immediately followed by Line Feed). In the following section on syn- 
tax it should be stressed that all characters in the argument field 
are ASCII characters. Thus a decimal integer shall mean an ASCII 
represented decimal integer. 
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The following are all the currently defined FTP commands: 


USER 


PASS 


ACCT 


REIN 


File Transfer Protocol 


<username> CRLF 
<password> CRLF 
<acctno> CRLF 


CRLF 


BYE CRLF 


BYTE 


SOCK 


LSTN 


TYPE 


FORM 


STRU 


MODE 


RETR 


STOR 


APPE 


ALLO 


REST 


RNFR 


RNTO 


ABOR 


DELE 


LIST 


NLST 


McKenzie 


<byte size> CRLF 
<HOST-socket> CRLF 
<direction> CRLF 
<type code> CRLF 
<form code> CRLF 
<structure code> CRLF 
<mode code> CRLF 
<pathname> CRLF 
<pathname> CRLF 
<pathname> CRLF 
<decimal integer> CRLF 
<marker> CRLF 
<pathname> CRLF 
<pathname> CRLF 

CRLF 

<pathname> CRLF 
<pathname> CRLF 


<pathname> CRLF 
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STAT <pathname> CRLF 
HELP <string> CRLF 
MLFL <users> CRLF 
MAIL <users> CRLF 
NOOP CRLF 

QUOT CRLF 

NQUO CRLF 


The syntax of the above argument fields (using BNF notation where 
applicable) is: 


<username> = <string> 

<password> = <string> 

<acctno> ::= <string> 

<string> = <empty>/<char>/<char><string> 

<char> ::= any of the 128 ASCII characters except CR and LF. 
<marker> ::= <pr string> 

<pr string> ::= <empty>/<pr char>/<pr char> <pr string> 

<pr char> ::= any ASCII code 33 through 126 

<byte size> ::= any decimal integer 1 through 255. 


<HOST-socket> <socket>/HOST number>,<socket> 


<HOST number> a decimal integer specifying an ARPANET HOST 


<socket> ::= decimal integer between 0 and (2%**32)-1 
<direction> = S/R 

<form code> ::= U/P 

<type code> = A/E/I/L 


<structure code> ::= F/R 
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<mode code> ::= S/B/T/H 

<pathname> ::= <string> 

<decimal integer> ::= <digit>/<digit><decimal integer> 
<digit> ::= 0]1/2|/3|4|5|6|7|[8|9 

<empty> = the null string (specifies use the default). 
<users> = <user>|<user, <users> 

<user> ::= <empty>|<NIC ident>|<sys ident> 

<NIC ident> ::= <string> 


<sys ident> <string> 


V.C Sequencing of Commands and Replies 


The communication between the user and server is intended to be an 
alternating dialogue. As such, the user issues an FTP command and 
the server responds with a prompt primary reply. The user should 
wait for this initial primary success or failure response before 
sending further commands. 


A second type of reply is sent asynchronously with respect to user 
commands. These replies may, for example, report on the progress or 
completion of file transfer and as such are secondary replies to file 
transfer commands. 


The third class of replies are informational and spontaneous replies 


which may arrive at any time. These replies are listed below as 
spontaneous. 
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COMMAND-REPLY CORRESPONDENCE TABLE 


COMMAND SUCCESS FAIL 

USER 230, 330 430-432,500-505, 507 

PASS 230,331 430-432,500-507 

ACCT 230 430-432,500-507 

REIN 2325233 401, 436,500-507 
Secondary Reply 300 

BYE 231,232 430-432,500-505, 507 

BYTE 200,331 500-507 

SOCK 200,331 500-505,507 

LSTN 2554-331 500-507 

TYPE 200,331 500-507 

FORM 200,331 500-507 

STRU 200,331 500-507 

MODE 200,331 500-507 

RETR 250,331 433,450,451, 454, 455, 500-505, 507, 550 
Secondary Reply 252 452 

STOR 250,331. 433,451,454, 455, 457, 500-505, 507, 550 
Secondary Reply 252 452,453 

APPE 250,331 433,451,454, 455, 457, 500-507, 550 
Secondary Reply 252 452,453 

ALLO 200,331 500-507 

REST 200,331 500-507 

RNFR 200,331 433,450,451, 455, 500-507, 550 

RNTO 253,331 433,450,451, 455, 456, 500-505, 507, 550 

ABOR 201,202,331 500-507 

DELE 254,331 433,450,451, 455, 500-507, 550 

LIST 250,331 433,450,451, 454, 455, 457, 500-507, 550 
Secondary Reply 252 452 

NLST 250,331 433,450,451, 454, 455, 457, 500-507 
Secondary Reply 252 452 

STAT 100,110,150, 450,451,454, 455,500-507, 550 

151,331 
HELP 000,030,050, 500-507 
331 

MLFL 250,331 433,450,451, 454, 455, 457, 500-507 
Secondary Reply 252 452,453 

MATL 331,350 433,450,451, 455, 500-507 
Secondary Reply 256 

NOOP 200 500-505,507 

QUOT 200,331 500-507 

NQUO 200 500-505,507 

Spontaneous Oxx, 300,301 400, 401, 434-436 

Replies 251,255 
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V.D Typical FTP Scenarios 
1. TIP User wanting to transfer file from HOST X to local printer: 
a) TIP user opens TELNET connections by ICP to HOST X, socket 3. 


b) The following commands and replies are exchanged: 


TIP HOST X 
USER username CRLF ---------- > 

GaSe Seea 330 Enter Password CRLF 

PASS password CRLF ---------- > 

{Sas SSsrs5 230 User logged in CRLF 

SOCK 65538 CRLF ---------- > 

e Sra 200 Command received OK CRLF 
RETR this.file CRLF ---------- > 
QSSSSSSSSS5 255 SOCK 5533 CRLF 


(HOST X initiates data connection to 
TIP socket 65538, i.e., PORT 1 receive) 


<---------- 250 File transfer started 
BYE CRLF # ----------------- > 
<---------- 252 File transfer completed 


c) HOST X closes the TELNET and data connections. 
Note: The TIP user should be in line mode. 

2. User at HOST U wanting to transfer files to/from HOST S: 
In general the user would communicate to the server via a mediat- 
ing user-FTP process. The following may be a typical scenario. 
The user-FTP prompts are shown in parentheses, ’---->’ represents 


commands from HOST U to HOST S, and '<----' represents replies 
from HOST S to HOST U. 
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Local Commands by User 


ftp (host) multics CR 

username Doe CR 

password mumble CR 

retrieve (local type) ASCII CR 


(local pathname) test 1 CR 
(for.pathname) test.pll CR 


type ImageCR 

byte 36CR 

store (local type) image CR 
(local pathname) file dump CR 
(for.pathname) >udd>cn>fd CR 


terminate 


File Transfer Protocol 


July 1972 


Action Involved 


ICP to HOST S, socket 3, 
establishing TELNET connections. 
USER Doe CRLF ----> 

<---- 330 password CRLF 

PASS mumble CRLF ----> 

<---- 230 Doe logged in. CRLF 


User-FTP opens local file in ASCII. 
RETR test.pll CRLF 


<---- 255 SOCK 1233 CRLF 

Server makes data connection to (Ut4). 
<---- 250 File transfer starts CRLF 
<---- 252 File transfer complete CRLF 
TYPE I CRLF ----> 

<---- 200 Command OK CRLF 

BYTE 36 CRLF ----> 

<---- 200 Command OK CRLF 


User-FTP opens local file in Image. 


STOR >udd>cn>fd CRLF ----> 
<---- 451 Access denied CRLF 
<---- 231 Doe logged out CRLF 


Server closes all connections. 


[ This RFC was put into machine readable form for entry ] 
[ into the online RFC archives by Via Genie 03/00 ] 
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